A. Field of the Invention
The present invention relates generally to computer networks, and more particularly to a virtualized network, that provides connection and automation via a real-to-virtual correspondence without the need for either systems or the systems development process.
B. Description of the Related Art
Things and actions are twisted or contorted in conventional computer system design processes. The more comprehensive the system the more pronounced such distortions. This condition occurs because there is no simple correspondence between the way things act in the real world and the way things act within the computer.
Stored program machines (or hardware platforms; i.e. ENIAC and its successors to this day) are viewed as calculators, giant brains, and what eventually stuck, as computers. The lack of correspondence is a direct consequence of this limited view of the stored program machine, the “computer” view.
From the very beginning, most people recognized the stored program machine as a powerful and general-purpose facility. It was acknowledged to be quite different from anything that preceded it. Yet people viewed it as a processor, and from the very beginning, persisted in calling it a processor, a calculator, a giant brain, or a computer. In doing so, and without conscious thought, the stored program machine was given a “personality.” Lost was its general-purpose attribute. It was/is assumed to be a processor, a computing device.
A device is connected to its end use or application by an arrangement or system. For every different application a different system is required. A connection standard is required if a single device is to handle more than one application. For a device (the stored program machine under this assumption) to start up and work through a second system, for a second application, requires special policies or procedures known as protocols. When a single stored program machine is applied to more than one use, independent of whether it is classed as system or user directed, the resultant systems, standards, and protocols make it complicated to operate and maintain.
Systems, with the standards and protocols they beget, are the costly burden that comes with the computer paradigm. Attempting to give life to a virtualized device and person entities becomes unnerving due to the apparent enormity of this task. Constructing the supporting systems, the systems enabling program entities to behave in a virtual environment, is seen as an overwhelming problem.
These difficulties arise from the fact that people view the processor as a device and so must live with systems, standards, and protocols.
An underlying problem has frustrated systems development and maintenance efforts for decades. Today the problem is subliminal and is taken as normal, but it was more visible and a clear disappointment early in the era of programmable machines (hardware platforms). Even then, an unadorned programmable machine, “did exactly what you told (or instructed) it to do”, accurately, faithfully, tirelessly—so its enormous value was perceived immediately. From the beginning, it seems, people held two basic expectations concerning the machine.
First, because it “does exactly what you tell it to do”, people believed it would be universally applicable, capable of automating any real world function or functions. This would become true as programmable machines connected, electrically, to more and different types of devices. And, over 50 years, this expectation has been realized, proved repeatedly. So today's culture retains great confidence that programmable machines, properly outfitted, configured and instructed, can automate any real world functions that can be described.
Second, again because it “does exactly what you tell (or instruct) it to do”, people believed they would be able to automate their own real world functions, by offloading those functions to a programmable machine just as one offloads organizational functions to a human subordinate or personal functions to a personal aide. Roughly speaking, they expected, that you would instruct the machine as you instruct your human helper thereby giving the job, the execution of the real world functions, to the machine.
However, this second expectation, that you could automate, offload or delegate frequent or routine real world functions—offloading them to a machine as you previously offloaded them to a subordinate, has not been realized. Telling the computer what to do turned out to be quite complex.
Throughout history, as individuals became less insular and more dependent upon one another, societies defined ever more specialized functions, specialization being the key ingredient in the success of societies. Organizations deliberately planned, grouped and parceled out functions. Indeed a prime purpose of organization was to separate function and responsibility into effective parcels. And the more specialized and limited functions became, the more they needed to interact, simply and directly, with other similarly specialized and limited functions. Specialized functions and constant interactions continue as a hallmark of today's society.
Unfortunately, in order to apply computers, to automate real world functions, an artificial system must be developed. Even perfectly proper real world functions must be reanalyzed, redefined and reorganized in order to automate them. They must go through a systems development process. The newly developed system then embodies or contains the re-represented functions. Since the original real functions were broken-down, redefined, and logically repositioned, in the systemization process, the interactions between the real and the reconstituted functions differ as well.
Only after systemization is the system ready to be encoded. But, encoding is like translating to a human helper who speaks a foreign language; it actually doesn't change the instructions; it just states those same instructions in a different language.
Nevertheless, the original user instructions, which would have been given directly to a real world subordinate, are twisted and distorted in the conventional systems development process. The programmable machine receives different instructions, about differently defined functions, with different logical interrelationships. To accomplish the very same job the machine and the subordinate must work from different scripts.
In the conventional use of programmable machines, functions as represented in the virtual world, inside machine memory, bear little resemblance to the original real world functions. So, the user, the supposed beneficiary of automation, no longer knows how his functions are being handled or how to explain the improvements he wishes to make. He looses control over his own automated functions (and usually is not held accountable for them). To make even the slightest change he must go back through the technology chain, through IT, outside consultants, enterprise-wide package suppliers and outsource vendors, with its multiple chances for misunderstanding, to eventually effect his smallest change.
Obviously, scrambled functions arise in the development of a single system. But once encoded, that single system is placed into the virtual world of machine memory amid a legacy of other, pre-existing systems. It must interact correctly with these systems. And in modern computers, user level functions depend upon many lower level system functions, each one of which has gone through its own systemization process.
Consider that a user system request which goes to/through an executive function, to/through a communications function, to/through a query language protocol function, to/through a security function (firewall), to/through a database function, to/through an I/O driver function just to read information, must fit correctly within a highly interdependent set of systems. The functions of any one system are interwoven and entwined with those of other systems. In general, the functions within one system cannot be changed without affecting the others. Once a part of this legacy of systems, every change, whether at the user or systems level, becomes a command decision.
In the end, then, telling the computer what to do turned out to be quite complex: (1) because of the technical difficulties of reanalyzing, redefining, and logically repositioning functions in the systems development and maintenance processes; (2) because of the loss of user familiarity with, and control over, the redefined, reconstituted and repositioned functions; and (3) because of the functional interdependency, the interweaving and entwining of newly automated functions with previously automated functions.
These problems have persisted and grown over 40 years. They will neither go away nor get better with time. Traditional use ensures that such problems will continue to be a frustrating and ever more costly legacy.
Until now no one seriously considered that programs might function for, i.e., virtualized devices operate for and virtualized persons live for, their counterpart real entities. If such programs could be made to absolutely mimic any action of their real, device or person counterpart, then the functions of those entities could be automated without systemization. Thus there exists a need for a network that provides real/virtual correspondence but without the very systems development efforts necessary in conventional computer systems.